Collaboration On The Blockchain

In this situation, that one event which completely adjusted the course of blockchain history was something called the DAO attack. For those who didn't read the past workshop about the history behind Ethereum, this particular event created a pause in the development of an application in particular that would expand upon the expansion and financial eligibility of Ethereum to the rest of the world. The term DAO, stands for Decentralized Autonomous Organization, which in 2016, was a method at which governance could be implemented on behalf of owners of a stake in a cryptocurrency, in order to adapt ‘Proof of Stake’ methods on applications such as Ethereum, and to also narrow the maximum security of validation for cryptocurrency miners. But in this article, we won’t be explaining that, but instead focusing on what led to the initial downfall and meticulous rise of the DAO that brings it the power it works under today.

As source code is the most important part of the cycle at which anything related to blockchain technology functions properly, this particular event fell victim to defects in the programming of the DAO process, ultimately creating a major financial loss that would test the feasibility of Ethereum as a yet, early cryptocurrency at the time. Justifiably, as much as the DAO concept was as early as the advantageous structure of Ethereum itself, this event in particular led to a security flaw that would importantly change the entire direction of how currencies were to work with applications.

In order to put it into a simple explanation, when it came to Ethereum, the specific security intrusion came when a hacker decided to take advantage of two important and relatively basic functions within the code. Since there’s a receiver and sender within an average transaction, in this particular case, there was the coding functions of receive() and withdraw(). Since a transaction, without the help of smart contracts of course, cannot work without this programming logic, it was figured at the time that you could corrupt the ‘calldata’ of the process in order keep withdrawing money from a currency without the balance of the users financial account changing.

For clarification, ‘calldata’ is the enacted storage base of the currency, or a collection of four data deposits of code that allows two functions within the code to communicate. An example could be that, I send someone ETH in exchange for a piece of digital property they agreed to sell to myself as the buyer, at which the calldata allows me to send through the currency amount within the conditions that a fallback() function doesn’t take place, at which the code and the financial data passed through a smart contract produces an error code if all the correct functions do not serve their roles in ensuring that a secure and validated buying and selling procedure takes place.

Now, the reason as to why there’s two core functions, receive() and withdraw() within the code is because a particular individual had to have withdrawn finances from their supposed accounts in order to ensure that the transaction of paying and receiving a digital commodity took place. The unfortunate circumstance here was that a re-entry attack took place, at which a hacker disguising themselves as a role within the network such as an investor, made sure that they could consistently withdraw vitalized currency money from multiple accounts at once without a specific receive() function taking place. Essentially, this person or group of people kept withdrawing money without letting the system know that there wasn’t a receiving end, which usually sparks a fallback function to take place.

Frankly, due to malicious code or a package that was installed into the network to begin with, this event had not taken place. All of these activities took place within the DAO smart contracts that ETH had first adapted at the time, leading to a major repercussion towards the security of millions of users at the time. As a chain must be formed at which users interact and validate each other's data, this malicious activity led to an inactive range of blocks, as thought of like a set of dominos that are falling behind each other synchronously. Altogether, the consequence of the event led to 5% of the total supply of ETH to be depleted, or in equivalence, 150$ million worth of the currency itself.

To remain specific before I discuss what the solution to the issue was, I will mention that the functions mentioned for the DAO-controlled smart contracts at the time were written under a programming language called Solidity. In order to solve the problem, the team behind Ethereum including that of the founder Vitalik Buterin himself, was to essentially write a fork under Ethereum that would completely reset the entire history of the currency itself, setting the value of it back to 0 and restarting all the work and investments put into making it work to begin with. This would essentially solve the initial withdrawing glitch the hacker would take advantage of, at which the withdraw() function would repeat itself without any indication of a receiving end existing from a different user holding a contract that would otherwise complete the transaction itself.

Other thoughts were to offer money to crypto miners within the network up to 100 ETH or even BTC, in order to stop them continuing their operations within the network, to make sure that absence in the network would lead to isolating the hackers unchanging balance. Since neither of these solutions were to work, one major addition was left to make ETH progress to the next level, and that was through a method called forking. In this case, the hackers were given a choice, at which they must adapt to a soft fork of the currency, which essentially means replicating the code and modifying it to split the complete user base into people who want to stick to an older version of the system, versus the users who want to move to a newer version instead. It’s like Microsoft asking an average PC user to upgrade to Windows 11, whereas some would like to solely focus on continuing to use Windows 10.

As this was not a valued solution, since the core use of the DAO contract would still exist for the hacker who found the glitch to begin with, the only alternative was to produce a hard fork, at which all users of the network were to switch to a brand new network at which the initial smart contract was to be duplicated, hence the birth of Ethereum Classic. To simply put, all users of the network would have to temporarily remain within an inactive chain, in order to upgrade to the smart contract method of Ethereum Classic, to continue mining and trading the core cryptocurrency.

This adaption to the solution remained highly successful, at which the soft fork method would only help to censor existing transactions on the network and to remove openness and visibility for those trading their finances, and to instead embark a hard fork that would completely remove censorship and introduce a new way at which overarching control of a central organization wouldn’t exist. Since the adaption of the hard fork method, the inactive chain which discontinued transactions past the 1,920,000th block within the network on 2016/07/20, would be continued under the Ethereum Classic contract format. The real importance of this development was that, one fault in the code of a major currency gave perspectives to the community that the most urgent events in the digitalized safety of people’s finances may always lead to the quickly initiated solutions of a team that proves both collaborative and ambitious towards their project. If ETC was not introduced at the rush of events, ETH would not exist today as a moving currency that revitalized what is now a custom path of transactional activity that drives how people interact with their information on a day-to-day basis, and surely wouldn’t have been done so without perseverance of the users passionate about the currency.

More details regarding this event will be explained in future workshops, ranging from the specifics in the behavior of the code itself, with a rundown as to what the program written by Solidity means, to the overall course of events that followed before, during, and after the attack.